小弟身為架構師的第一年，想想沒有架構比YT還要困難且麻煩，牽扯到影音轉檔、快取、大流量等問題，就決定趁著鐵人賽實做看看微Youtube。如果有錯誤歡迎指教，第一天我們就從大規模的專案熱愛的微服務開始說起！

談微服務之前，先談談單體式應用程式

事情總是有先來後到，在微服務被推行出來之前，有一個通俗大家常見的架構，叫做單體式應用程式(Monolithic application)。通常在單體架構下，所有的feature會混在一起放在同一個server內。再藉由router去做切換。

當專案複雜度不高的時候，架構或開發是很簡單的，測試跟部署也很簡單，因為只需要管一個server。

這邊我們得到單體式架構的兩個優點，在專案複雜度不高時

1. 架構簡單，易於部署
2. 開發快速，方便測試

但當你的專案架構開始複雜，舉例來說，新增聊天室功能，因為聊天室的實作通常會使用websocket這類在server及 client中間建立持續連線的方式，於是你的架構不再是一個req對res的關係。或者是我們新增推薦系統，因為推薦系統會牽扯到cache，於是你在架構中新增redis，但其他服務並沒有依賴於相關的功能。

所以我們得到單體式架構的四個缺點，當你的專案逐漸複雜時

1. 改功能要小心可能不小心就動到別的服務
2. 使用人數爆炸時，水平擴充redis或是websocket會變得很麻煩
3. 假設前人使用的是 Node開發，但新接手的團隊只會寫 Go，server環境會超級混雜
4. 專案規模一大，部署及測試的時間拉長。而且因為服務塞在一塊，你改一個聊天室功能，要跑完其他全部測試（整合測試情況下）

也因為單體式架構的缺點在大型專案或是多人協作的狀況下成為了嚴重的痛點，於是有了微服務的誕生。

微服務的概念

微服務就是將單一應用程式劃分成多個小型服務。各服務各自執行獨立的程序，並且利用API溝通。各服務以企業業務邏輯會基礎發展。

以上面案例來說，就是我們將聊天室的服務隔離出來，讓他變成另一個應用程式，然後當使用者在呼叫聊天室功能的時候，其實走的都是聊天室這邊的應用程式服務。當我們拉出來額外做應用程式有哪些好處呢？

1. 微服務架構可以更有效地使用基礎設施，因為服務完全獨立，所以我們可以根據需求水平擴充與縮減。
2. 多團隊專注在各自服務開發，不用擔心衝突，加速開發流程
3. 更快的迭代新的版本和更短的停機時間

但你說微服務就無敵了嗎？不竟然，想想原本簡單的一個server被我們多拆分成好幾塊，如何讓他們有良好的溝通互動就成了問題。而不只是程式間的互動，開發者間的溝通也變得至關重要。這也跟DevOps的文化興起有關聯

另外，系統運作難免會出問題，但微服務是靠著許多鬆散耦合（Loosely-Coupled）的服務組成，假設你有數十數百個微服務要管理，「你會不容易發現問題在哪」，所以對於基本監控的項目包含系統出錯的次數以及服務可用性要有很高的掌握度。

所以我們整理出微服務的幾個難點

1. 團隊要有高度自動化，具備快速建置的能力
2. 應用程式監控機制，因分散鬆散的結構，不容易發現問題，必須有監控項目包含出錯次數與服務可用性
3. 快速部署，呼應第一點且無論測試、正式，都要能快速部署，未來設法全部自動化。

額外參考

如果你已經是單體式應用程式，你是否應該轉向到微服務，我認為可以參考

1. 單體式系統到微服務這本書
2. 或是這篇：https://yuanchieh.page/posts/2021/2021-12-03-單體式系統到微服務讀後分享-上/，

程式的世界有趣的點就是沒有絕對，或許你能找到更好的方式解決問題。

微服務是在 SOA概念上陸續被實踐的方法，想了解更多可以參考：

SOA vs. Microservices https://www.ibm.com/cloud/blog/soa-vs-microservices
Microsrevices 微服務架構 https://ithelp.ithome.com.tw/articles/10228461

我們這次專案將會以微服務的概念規劃架構，並以”微”Youtube作為目標來挑戰設計。

參考資源

1. Google Cloud 什麼是微服務架構？ https://cloud.google.com/learn/what-is-microservices-architecture?hl=zh-tw
2. 髒桶子 微服務真的有那麼好？ https://ithelp.ithome.com.tw/articles/10237712
3. 微服务架构设计 https://gudaoxuri.gitbook.io/microservices-architecture/